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addition to the one defined by ODP (Open Distributed Processing) and adopted by TINA 
(Telecommunication Information Networking Architecture). 




29. Arrangement as claimed in clairH 27, characterized in that said mobility 
transparency means areNntroduced to the application designers at the requirement and 
functional specification phases, i.e., by integrating mobility function (M) totally into the 
infrastructure of a platform. 

30. Arrangement as claimed in claim 27, characterized in that said mobility 
transparency means are so adapted that computational objects are mapped to engineering 
objects (EO) so as to be none-visible in the computational model of the application in question. 




31. Arrangement as claimed in claim 27, characterized in that the mobility function 
constitutes the engineering object interceptor, i.e., being arranged at the boundary between the 
terminal domain and the telecom system aomain. 

32. Arrangement as claimed in claim 27, characterized in that an engineering model is 
developed by letting each computational object (CO) be mapped to one or more Basic 
Engineering Objects (BEOs), interaction between computational objects (COl, C02) belonging 
to the same cluster being effected directly as method calls, and communications between 
computational objects (C03, C04) located in the telecom system domain and in different 
clusters being effected through a channel comprising; stubs, binders and protocols. 



33. Arrangement as claimed in claini^27, characterized in that communication between 
user domain computation objects (C02) and telecom swtem domain computation object (C03) 
residing in different clusters will take place in a channel comprising an interceptor ( ) in 

\ — : * 

addition to the usual objects, said interceptor being invisible for the application designer. 




34. Arrangement as claimed in claim\£7, characterized in that from the computational 
model the application designer can decide whether an object Belongs to the user domain or the 
telecom system domain, for on the basis of such a decision to generate the necessary objects, 
such as stubs, for all the application objects. 
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35. ArWngement as claimed in claim 27, characterized in that the arrangement 
fj comprises means for sending a message to a routing broker asking for specific server to perform 
^ a task, said broker locating the server and sending said request to said server, said mobility 
functions (M) thereby playing the role as the broker. 

*THP 36. Arrangement as claimed in claim 27, characterized in that said mobility function 

(M) comprises a cascade of Avo brokers. 




37. 



Arrangement as claimed in claih^27, characterized in that said mobility functions 



(M) in the form of two brokers allows for interaction between an object (COl) belonging to a 
user domain and an object (C02) Belonging to a telecom system 

domain by letting said interactions enter said mobility functions (M) at one end and exit 
therefrom at the other end. 




38. (Amended) Arrangement as claimed in claim 27, characterized in that both ends of 
the mobility functions (M) support both me same interface type containing an "invoke type" 
operation, for thereby allowing a request to\be built and invoked dynamically by client objects. 




39. Arrangement as in claim 38, characterized in that there is used an invoke operation, 
which invoke comprises an object name (or identifier), an operation name, and a parameter list 
for the invoked operation. 

40. Arrangement as claimed in claim 27, characterized in that the mobility functions 
(M) are introduced in the system architecture as a fiiqctional layer between the application layer 
and the DPE layer, said layer separation allowing everjt layers to use services offered by other 
layers. 



41. Arrangement as claimed in claim 27, characterized in that there is introduced an 
intermediary model called derived computational model invthe transition from the 
computational model to the engineering model, said intermediary model being used to map all 
interactions traversing the boundary between the user domaim and the telecom system domain 
to interactions with the mobility functions (M). 
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42. Arrangement as claimed in claiid 41, characterized in that on the basis of the 
derived computational model, an engineering model can be elaborated and engineering objects, 
such as stubs, can be mechanically generated. 




43. ArrangementVs claimed in claiVn 27, characterized in that said arrangement 
comprises proxy objects, a pYoxy acting on behalf of an entity in a transparent way, i.e. 3 when 
interacting with a proxy an entity cannot tell whether it is dealing with the real counterpart or 
with its proxy. 

44. Arrangement as claimed in clain\ 43, characterized in that the proxy is adapted to 
marshal the operation invocation iiko an invoke operation at the respective end of the mobility 
functions. 

45. Arrangement as claimed in claihi 44, characterized in that the proxy is introduced 
as a symmetrical constellation if interactions are to be in both directions. 

46. Arrangement as claimed in cl^pi 45, characterized in that the necessary proxies are 
introduced and created according to the communications needs, alternatively dynamically at run- 
time. 




47. Arrangement as claimed in claim 2\ characterized in that there is introduced an 
object type designated Dynamic Object (DO), allproxies being of the type DO, and that a 
proxy, i.e. a an object (instance) of type DO is initiated from an object template called Dynamic 
Object Implementation (DOI). 




48. Arrangement as claimed in claitn 47, characterized in that a proxy represents one 
and only one object, a proxy being deleted when the represented object terminates, alternatively 
that an object can be represented by multiple proxies, e.g., one proxy for each client object 



49. Arrangement as claimed in claims, characterized in that any object wanting to 
interact with objects in a different domain are registered intthe mobility functions (M), the 
registration of the necessary objects for an application being\done for example at the 
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